For ease of reference, we begin with a list of abbreviations which will be used throughout this specification:    SCN—Signaling Control Network    NCC—Network Call Controller    NCCG—Network Call Controller Gateway    CC—Connection Controller    CCC—Client Call Controller    UNI—User to Network Interface    E-NNI—External Network to Network Interface    SNPP—Subnetwork Point Pool    OIF—Optical Internetworking Forum
Modern communication networks are characterized by a large number of interconnected networks each of which may implement any one or more of a variety of transport protocols (e.g. Ethernet, ATM, TCP/IP; SONET/SDH). Where interconnected networks employ different transport protocols, adaptation services provided by the gateway servers facilitate transport of client data between the involved networks. In response to the demand for seamless communications across this “network of networks”, much effort has been made to develop generic connection management schemes that can be utilized by network service providers independently of the transport technology used. This work has resulted in the International Telecommunications Union (ITU) standard Recommendation G.805, which defines a layered functional architecture for transport networks. The transport (bearer) plane has an architecture described in G.805—which involves transport layers, e.g. VC 4, STM-1 layer, etc. G.805 discusses how layers relate by multiplexing one layer into another (E.g., multiplexing multiple DSOs into a DS1, or according to the SDH or SONET hierarchy), in a process called adaptation. Two related transport plane layers are related (i.e., one is adapted into another) in a client-server relationship (e.g., 28×64 kb voice DS0 layers are multiplexed into a DS1). Such a relationship is recursive in nature as a first layer can be adapted into a second layer which in turn can be adapted into a third layer, etc.
Typically each protocol exists at a different layer. Furthermore, different business entities exist, and each may use different layers as well. Typically a control plane is associated with each transport (bearer) plane. Based on the G.805 layer architecture two models have been developed: G.8080 for the control plane (Automatically Switched Optical Network—ASON); and Tele-Management Forum (TMF) model TMF608 for the management plane. TMF814 is an interface specification of TMF that instantiates the TMF608 model. G.8080 defines two types of call controllers: calling/called party call controllers (CCCs); and network call controllers (NCCs). Calling/called party call controllers initiate and terminate calls, whereas network call controllers interact with the CCCs and with connection controllers to manage connections within the network. Within the management plane, TMF814 provides an interface that uses the G.805 model of connections. The relationship between connections at different layers is known in the TMF814 interface. Thus it can be used to manage multi-layer connections across the network.
Carrier transport networks typically use a Signaling Control Network (SCN) to allow call controllers to talk to each other. An SCN is typically a separate network from the transport plane and is used to allow NCCs to communicate. This is often used for control plane signaling, or to allow management functions from existing SONET networks, which do not have control planes, to interact with NEs.
Typically each carrier uses its own SCN and each layer may use separate SCNs. Furthermore, even within a single carrier, there may be different divisions which control particular services, which each operate with some level of autonomy. This can lead to different domains within a single carrier, and consequently multiple SCNs within a single layer. Note that more than one carrier may be co-located due to access requirements and corresponding regulations, which can also produce multiple SCNs within a layer.
A limitation of Recommendation G.8080/Y.1304 [2] (that is, the “Architecture of the Automatically Switched Optical Network”—ASON) was that it was defined for a single-layered control plane. Recently, there have been proposed improvements to rectify this limitation in the Recommendation. This improvement added the capability for inter layer calls which preserves independence between control planes per layer. In addition, a proposal for a call control using a layered call model is described in United States Patent Application 20050074029, “Call control using a layered call model”, Apr. 7, 2005, which is assigned to the assignee of the present application, and which is hereby incorporated by reference.
There are two ways to achieve signaling in a multi-layer context. The first solution consists of embedding the first layer signaling in the second layer signaling. This leads to additional signaling on the server layer and the SCN at the server layer may need to be designed to support additional control traffic. In order to be recursive, a layer may need to carry embedded client layer information that may in turn carry embedded client layer information for the layer above. Since there is no bound on the number of layers, it may be difficult to design an SCN that will satisfy the requirements recursively.
The second solution consists of performing independent signaling at each layer, as discussed in Optical Internetworking Forum contribution (OIF) 2005.088.07, “OIF Supercomm 2005 Demo Control Plane Protocol Specification”, October 2005 (hereafter referred to as the OIF 2005 demo), which is hereby incorporated by reference. For the demo, a single SCN was assumed to provide signaling connectivity between any call controller pair, regardless of layer. The solution used for the OIF 2005 demo consisted of signaling client layer SCN information at the server layer, allowing the client layer to setup a signaling adjacency and perform signaling directly at the client layer.
There are problems with the approach used in OIF 2005 demo described above. It does not work when two client layer NCCs are on separate SCNs as they don't have visibility of one another and don't know how to reach the other NCC. It also does not accommodate the scenario where there are control channel boundaries in the client layer that arise due to multiple SCNs in the client layer itself between the source and destination call controllers.
Scenarios where different layers have different SCNs are described in Optical Internetworking Forum contribution 2006.105.00, “Interlayer Architecture for UNI 2.0 and ENNI 2.0”, May 2006, which is hereby incorporated by reference. However, no solution is provided for allowing the client layer NCCs to communicate across multiple SCNs.
It is, therefore, desirable to provide a way for a call that is originated at one layer, to use the resources of another layer to complete the call, when multiple SCNs exist between the call end points.